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1—5 ■ Abstract 

o' 

CNl 1 We show how to use aspect-oriented programming to separate security and trust issues 

from the logical design of mobile, distributed systems. The main challenge is how to 
enforce various types of security policies, in particular predictive access control policies - 
p ^ policies based on the future behavior of a program. A novel feature of our approach is 

that advice is able to analyze the future use of data. We consider a number of different 
, security policies, concerning both primary and secondary use of data, some of which can 

only be enforced by analysis of process continuations. 

>: 

^ ; 1 Introduction 

(N 

Whilst there is broad agreement that security and other non-functional properties should be 
<^> designed into systems ab initio it is also recognized that, as society becomes more IT-savvy, 

our expectations about security and privacy evolve. This is usually followed by changes in 
regulation in the form of standards and legislation. Thus, whilst we would still argue that 
security should feature in the initial design of a system, there is merit in separating out 
^ 1 security and other non-functional properties so that they can be updated without disturbing 

^ ■ the functional aspects of the system. 

This paper focuses on designing a language for specifying policies for access control and 
explicit flow of information. The traditional approach to enforcing such security policies is to 
use a reference monitor [T] that dynamically tracks the execution of the program; it makes 
appropriate checks on each basic operation being performed, either blocking the operation or 
allowing it to proceed. In concrete systems this is implemented as part of the operating system 
or as part of the interpreter for the language at hand (e.g. the Java byte code interpreter); 
in both cases as part of the trusted computing base. Sometimes it is found to be more cost 
effective to systematically modify the code so as to explicitly perform the checks that the 
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reference monitor would otherwise have imposed [2]. In any case, even small modification in 
the security policies may involve substantial changes in the code or the underlying system. 

The notion of aspect- oriented programming [31 Hj is an interesting approach to separation of 
concerns. The enforcement of security policies is an obvious candidate for such separation of 
concerns, e.g. because the security policy can be implemented by more skilled or more trusted 
programmers, or indeed because security considerations can be retrofitted by (re)defining 
advice to suit the (new) security policy. The detailed definition of the advice will then make 
decisions about how to possibly modify the operation being trapped. This calls for a modified 
language (like AspectJ [3] for Java) that supports the use of aspects and where a notion of 
trapping operations and applying advice has been incorporated. It is possible to systematically 
modify the code so as to explicitly perform the operations that the advice would have imposed 
(e.g. 0). 

In many cases the aspect-oriented approach provides a more flexible way for dealing with 
modifications in security policies El El El [9] than the use of reference monitors. It facilitates 
the use of frameworks for security policies that may be well suited to the task at hand but 
that are perhaps not of general applicability and therefore not appropriate for incorporating 
into a reference monitor. 

Outline of the paper. In this paper we are primarily interested in the modelling of mobile, 
distributed systems. The work is based on the coordination language KLAIM [10] (reviewed 
in Section [2]) that facilitates distribution of data, mobility of code and handling of dynamically 
evolving, open systems. The main contribution of the paper is the design of AspectKE, an 
aspect-oriented extension of KLAIM that facilitates the trapping of actions (presented in 
Section [3]) as well as processes (presented in Section [5]), which can enforce traditional access 
control policies (presented in Section U]) as well as predictive access control policies (presented 
in Section [6]) - i.e., security policies based on the future behavior of a program. 

To evaluate our language design we shall throughout the paper illustrate its features using 
a running example based on a health information system for a care facility for the elderly 
people in New South Wales, Australia [11] . In Section [5] we show how to use AspectKE to 
enforce basic primary use of data policies, that is, policies concerned with the right to access 
data. Here we consider the three classical access control models, namely discretionary access 
control, mandatory access control and role-based access control pQ. Furthermore, we illustrate 
how multiple security policies can be integrated into existing systems thereby allowing policies 
to be refined at later stages in the system development. In Section [6] we show how secondary 
use of data policies can be modelled; these policies are concerned with how data is used once 
it has been obtained [12]. They can be enforced by using predictive access control policy 
enforcement mechanism offered by AspectKE. Here we exploit the ability to analyze not only 
the behavior of remotely executed processes but also the future use of data. To the best of 
our knowledge few, if any, proposals have ever used aspect oriented programming to tackle 
secondary use of data policies and provide a predictive access control policy enforcement 
mechanism. 

Finally, in Section [7] we present related work and we conclude in Section [8] with a discussion of 
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Table 1: KLAIM Syntax - Nets, Processes and Actions (Part of AspectKE). 



the experience gathered from a proof-of-concept implementation [13] and outline some future 
work. 

2 Background: KLAIM 

AspectKE is an extension of the KLAIM {Kernel Language for Agents Interaction and Mobil- 
ity) coordination language [10] with support for aspect oriented programming. In this section 
we will review the fragment of KLAIM that will be used for AspectKE in the following section. 

KLAIM is a language specifically designed to program distributed systems consisting of sev- 
eral mobile components that interact through multiple distributed tuple spaces (databases). 
KLAIM uses a Linda-like generative communication model |14j but, instead of using Linda's 
global shared tuple space (shared database), KLAIM associates a local tuple space with each 
node of a net. Each node may also have processes associated with it; the KLAIM computing 
primitives allow programmers to distribute and retrieve data and processes to and from loca- 
tions (nodes) of a net, evaluate processes at remote locations and introduce new locations to 
the net. 

2.1 Syntax of KLAIM 

The syntax of a fragment of KLAIM is displayed in Table [U 

A net (in Net) is a parallel composition of located processes and/or located tuples. For 
simplicity, components of tuples can be location constants onljQ. We use the notation / to 
represent a sequence of location constants and e is used to represent the empty sequence. Nets 
must be closed: all variables must be in the scope of a defining occurrence (indicated by an 
exclamation mark). 

A process (in Proc) can be a parallel composition of processes, a guarded sum of action 
prefixed processes, or a replicated process (indicated by the * operator). We write for a 

1 Compared with the original KLAIM, we do not allow processes to be components of tuples. 
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miliary sum, a.P for a unary sum, and a\.P\ + a^-Pi for a binary sum. 

An action (in Act) operates on locations, tuples and processes: a tuple can be output to, 
input from (read and delete the source) and read from (read and keep the source) a location; 
processes can be spawned at a location; new locations can also be created. The actual 
operation performed by an action is called a capability (in Cap) - this is a key concept when 
formalizing uses of data later. We do not distinguish real locations and data: all of them 
are called locations (in Loc) in our setting, which can be location constants I, defining (i.e. 
binding) occurrences of location variables \u (where the scope is the entire process to the right 
of the occurrence), and use of location variables u. 

Well-Formedness of Locations and Actions. We do not allow multiple defining occur- 
rences of the same variable in an action. We also prohibit bound variables and free variables 
from sharing any name in a single action. Thus we disallow in(!it, \u)@l as well as in(\u, u)@l. 

2.2 Semantics of KLAIM 

Informally the meaning of a KLAIM program is as follows: 

1. a node is selected for the next step of execution 

2. if the process at the node is a choice, then one of the enabled choices is chosen non- 
deterministically and executed as described in the following four steps 

3. if the prefix of the process is an output action, the output is performed 

4. if the prefix of the process is an input (either destructive or non-destructive), the input 
action is enabled if there is a matching tuple at the target location, and the input is 
performed and appropriate variables are bound in the remainder of the process 

5. if the prefix is an eval, the process is spawned at the target location 

6. if the prefix is a newloc, the network is dynamically extended with a new location and 
the continuation process is given the address of that location 

7. then return to Step Q] 

Notice that we do not need to deal with parallelism and replication within nodes because, at 
the cost of having duplicate addresses in the network, these can be lifted to the net level. 

2.3 Running Example 

Health Care Information Systems are gradually becoming prevalent and indispensable to our 
society. An electronic health record (EHR), part of a system's database, stores a patient's 
data and is created, developed, and maintained by the health care providers. 
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To illustrate the use of KLAIM, we now introduce a typical EHR system, which is inspired 
by [11], and the scenario presented here is used throughout the paper. 

The EHR database (EHDB) stores all patient healthcare records and we assume that there 
are two types of data recorded for each patient: medical records (MedicalRecord) and private 
notes (PrivateNote). Medical records are entries created by doctors and so are the private 
notes; however the latter are of a more confidential nature. Also we distinguish between past 
records (Past) that have been entered into the EHR system previously and recent records 
(Recent) that have been created since the patient was admitted to the hospital. We therefore 
assume that the EHR database contains tuples with the following five fields: 



patient 


The name of the patient 


recordtype 


The type of record: MedicalRecord or PrivateNote 


author 


The author of the record 


createdtime 


The time of creation of the record: Recent or Past 


subject 


The record's content 



For example (Alice, MedicalRecord, DrSmith, Recent, text) is a recent medical record of Alice, 
created by DrSmith and it has content text. 

Doctors and nurses, as well as the patient, can access a patient's record. We model these 
actors as locations in a network; the process at the location represents the actions of the 
individual and the data is the individual's local "knowledge". As an example the following 
process expresses that DrSmith reads one of the Past medical records for Alice created by 
DrHansen before she was admitted to this hospital, writes some of the information in her own 
note (in location DrSmith) and then creates a new medical record for the patient: 

DrSmith :: read(Alice, MedicalRecord, DrHansen, Past, lcontent)@EHDB. 
out(Alice, content)@DrSm\th. 

out(Alice, MedicalRecord, DrSmith, Recent, newtext)@EHDB 

Here DrSmith will first consult location EHDB and read a five-tuple whose first four com- 
ponents are Alice, MedicalRecord, DrHansen, and Past respectively and the corresponding fifth 
component is assigned to variable content. The second action will write the content read at 
the first action to the location associated with DrSmith. The final construct will write a new 
five-tuple to location EHDB for this patient whose last three components indicate that the 
author is DrSmith, it is a Recent medical record and the content is newtext. 

To illustrate the semantics of KLAIM let us consider the following net, consisting of locations 
EHDB and DrSmith: 

EHDB :: (Alice, MedicalRecord, DrHansen, Past, alicetext) 
| EHDB :: (Bob, PrivateNote, DrJensen, Recent, bobtext) 
I DrSmith :: read(Alice, MedicalRecord, DrHansen, Past, !conierrf)@ EHDB. 
out(Alice, conier7i)@DrSmith. 

out(Alice, MedicalRecord, DrSmith, Recent, newtext)@EHDB 
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The execution may proceed as follows: 

EHDB :: (Alice, MedicalRecord, DrHansen, Past, alicetext) 
|| EHDB :: (Bob, PrivateNote, DrJensen, Recent, bobtext) 

DrSmith :: read(Alice, MedicalRecord, DrHansen, Past, lcontent)@EHDB. 
out(Alice, content)@D rSmith. 

out(Alice, MedicalRecord, DrSmith, Recent, newtext)@EHDB 

— > 

EHDB :: (Alice, MedicalRecord, DrHansen, Past, alicetext) 
|| EHDB :: (Bob, PrivateNote, DrJensen, Recent, bobtext) 
DrSmith :: out(Alice, alicetext)@DrSmith. 

out(Alice, MedicalRecord, DrSmith, Recent, newtext)@EHDB 

-¥ 

EHDB :: (Alice, MedicalRecord, DrHansen, Past, alicetext) 
|| EHDB :: (Bob, PrivateNote, DrJensen, Recent, bobtext) 
DrSmith :: (Alice, alicetext) 

DrSmith :: out(Alice, MedicalRecord, DrSmith, Recent, newtext)@EHDB 



EHDB :: (Alice, MedicalRecord, DrHansen, Past, alicetext) 
EHDB :: (Alice, MedicalRecord, DrSmith, Recent, newtext) 
jj EHDB :: (Bob, PrivateNote, DrJensen, Recent, bobtext) 
DrSmith :: (Alice, alicetext) 

DrSmith first reads the tuple (Alice, MedicalRecord, DrHansen, Past, alicetext) from EHDB; the 
binding of the variable content is reflected in the continuation of the process. In the second 
step DrSmith outputs a tuple that consists of Alice together with a bound content (alicetext) 
to her own tuple space. In the final step, a new tuple that represents a new medical record is 
written to location EHDB. 

3 AspectKE: Trapping Actions 

We now show how to integrate aspects into KLAIM by presenting the basic features of 
AspectKE, with a focus on how aspects trap actions in a KLAIM program. We consider 
a global set of aspects. 

3.1 Syntax 

The Syntax of AspectKE is given by Tables [2] and [T] (the KLAIM syntax). 

Table [2] introduces a system S (in System) that consists of a net N and a sequence of global 
aspect declarations asf>. An aspect declaration (in Asp) takes the form A[cui] = body: A is 
the aspect name, and body (in Advice) is the advice to the trapped action. Each action (the 
Act in Table [I]) is a potential join point that can be intercepted by AspectKE's pointcut (in 
Cut). 
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Table 2: AspectKE Syntax - Aspects for Trapping Actions 



Moreover, _ is introduced as a don't-care parameter in the cut version of actions, and in the 
test primitive of conditional expressions (BExp). It can match any type of location used in 
the program. Note in the cut, the occurrence of \u and u have different meaning from those 
of KLAIM; a plain variable in a pointcut can only match an actual location and banged (!) 
variables in the pointcut can only match against binding occurrences of variables, while the 
don't-care (_) can match both in the join point. 

Each aspect gives a unique run-time suggestion (either break or proceed) which may de- 
pend on the evaluation of a conditional expression. The suggestion break suppresses the 
trapped action whilst proceed allows the trapped action to be executed. In case of mul- 
tiple aspects that trap an action, break takes precedence over proceed. The primitive 
test(^)@£ evaluates to tt if a tuple exists in the tuple space of t which matches it . Besides 
basic boolean expressions, condition cond also includes bounded existential quantification and 
universal quantification - this allows simple queries to the databases occurring in the nets. 

In contrast to other aspect languages, the condition is part of the advice instead of being part 
of the pointcut (being evaluated before intercepting a join point). Evaluating the condition 
after intercepting a join point allows a more natural modelling of security policies. 

Well-formedness of Cuts. In addition to the well-formedness conditions for KLAIM, we 
require that the variables in a cut are pairwise distinct. We shall also impose that aspects are 
closed: any free variable in the body is defined in the cut. Additionally, when !u is used in a 
cut pattern, u should not be used in conditions except in the context of set expressions. 

Example 1 To illustrate how aspects can be composed in AspectKE that work with the KLAIM 
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program, the following simple aspect gives advice to the running example in section \2.3l 



kl ut [user :: out(_, data)@DrSmith] 
= case(data = alicetext) 
break; 
proceed 

The aspect traps an out action of processes running at location DrSmith that attempt to send 
a tuple with two fields. If the actual value of the second field is equal to alicetext, the aspect 
will break the execution of the action and its continuation process. Otherwise, the action 
continues. 



3.2 Semantics 

The base semantics is that of KLAIM (Section [2]) but now, before executing an action (all 
actions in a KLAIM program are potential join points), we check to see if any aspect applies 
to the action and combine the advice of all applicable aspects. Each advice is either that the 
action be allowed to proceed or not. We resolve possible conflicts by ensuring that any aspect 
that disallows an action has priority. Aspects are applied in definition order but, because 
aspects can only allow or disallow the join point to proceed, the order is actually immaterial. 



Example 2 Suppose we have a system that contains the same net as in running example of 
Section \2.3\ and aspect A° ut in Example Q* 

f\l ut [user :: out(_, data)@DrSmith] 

, , = c&se(data = alicetext) 

let , , in 

break; 

proceed 

EHDB :: (Alice, Medical Record, DrHansen, Past, alicetext) 
|| EHDB :: (Bob, PrivateNote, DrJensen, Recent, bobtext) 

DrSmith :: read(Alice, MedicalRecord, DrHansen, Past, \content)@EHDB. 
out(Alice, content)@DrSm\th. 

out(Alice, MedicalRecord, DrSmith, Recent, newtext)@EHDB 

and some steps of execution (omitting the aspect definition): 
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EHDB :: (Alice, Medical Record, DrHansen, Past, alicetext) 
|| EHDB :: (Bob, PrivateNote, DrJensen, Recent, bobtext) 

DrSmith :: read(Alice, MedicalRecord, DrHansen, Past, lcontent)@EHDB. 
out(Alice, content)@DrSm\th. 

out(Alice, MedicalRecord, DrSmith, Recent, newtext)@EHDB 

-> 

EHDB :: (Alice, MedicalRecord, DrHansen, Past, alicetext) 
|| EHDB :: (Bob, PrivateNote, DrJensen, Recent, bobtext) 
DrSmith :: out(Alice, alicetext)@DrSmith. 

out(Alice, MedicalRecord, DrSmith, Recent, newtext)@EHDB 

— > 

EHDB :: (Alice, MedicalRecord, DrHansen, Past, alicetext) 
|| EHDB :: (Bob, PrivateNote, DrJensen, Recent, bobtext) 
DrSmith :: 

Aspect A° u * does not trap the read action, thus the read action executes and binds content 
with alicetext. But A° ut traps the first out action, and the result substitution is 

[DrSmith/use7-, alicetext/data] 

and the case condition data = alicetext evaluates to tt, thus the aspect breaks the execution of 
this action and its continuation process. 

4 Worked Examples: Advice for Access Control Models 

To evaluate the expressiveness of the language and show its language features, we now show 
how AspectKE can be used to enforce access control policies by utilizing three well-known 
access control models, namely discretionary access control (Section I4.ip . mandatory access 
control (Section I4.2|) and role-based access control (Section I4.3|) . and how AspectKE can 
introduce new aspects for retrofitting new policies to existing systems (Section 14. 4p . 

Since patient confidentiality is an important issue in the health care industry it is imperative 
that EHRs are protected [15]. To help achieve this goal, governments define many types of 
security policies, encapsulated in various acts and guides (e.g. [TBJ E]). Throughout the 
paper, we will enforce several security policies for the EHR system that was introduced in 
Section 12.31 and this shows different features of the language. 

The first is a primary use of data policy inspired by which regulates the basic access 
control concerning the read and write rights owned by doctors and nurses: 

Doctors can read all patients ' medical records and private notes, while nurses can 
read all patients ' medical records but cannot read any private notes. Medical records 
and private notes can only be created by doctors. 

For simplicity, here we restrict ourselves to only focussing on read, in and out actions, while 
eval and newloc actions will be discussed further when enforcing other security policies. 
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4.1 Discretionary Access Control 



We will show how to enforce the above policy with discretionary access control (DAC), which 
is a type of access control as a means of restricting access to objects based on the identity 
of subjects and/or the groups to which they belong[18]. We do so by using an access control 
matrix containing triples (s, o, c) identifying which subjects s can perform which operations c 
on which objects o. If we use the KLAIM programming model, we should equip the semantics 
of KLAIM with a reference monitor that consults the access control matrix when an action 
is executed to check if the action is permitted. In AspectKE we can directly use aspects to 
elegantly inline the reference monitor to enforce this discretionary access control policy. 

Example 3 The access control matrix is stored in location DAC, which contains tuples: 
{user, recordtype, capability). For example, if DrSmith is a doctor and NsOlsen is a nurse, 
then DAC might contain the following tuples: 

(DrSmith, MedicalRecord, read) 
(DrSmith, PrivatelMote, read) 
(DrSmith, MedicalRecord, out) 
(DrSmith, PrivatelMote, out) 
(NsOlsen, MedicalRecord, read) 

We also assume that the location DAC can only be modified by privileged users, thus doctors 
and nurses cannot perform any in and out action on it. This can be enforced by other aspects 
but we omit them here. 

The following aspect declarations will impose the desired requirements. 

A£f^ d [user :: read(_, recordtype, _,_,_)© EH DB] 
= case(test(«ser, recordtype, read)@DAC) 
proceed; 
break 

A pi A2 [user :: in(_, recordtype, _, _, _)@EHDB] 
= case(test(user, recordtype, in)@DAC) 
proceed; 
break 

A°f M [user :: out(_, recordtype, _,_,_)@EHDB] 
= case (test (user, recordtype, out)@DAC) 
proceed; 
break 

Aspects A^, A p " 1a2 , and 

ApU 3 enforce the above policy by using DAC, where the access rights 
for each user are actually described. Note that the second field of the tuple operated by these 
cut actions is recordtype, which trap an action that clearly specifies a concrete record type. 

Consider the following KLAIM program that is a variant of the running example in Section 
\2.3\ (in that the user is nurse NsOlsen instead of doctor DrSmithj and is equipped with the 
above four aspects: 

NsOlsen :: read(Alice, MedicalRecord, DrHansen, Past, \content)@EHDB. 
out(Alice, conterii)@NsOlsen. 

out(Alice, MedicalRecord, NsOlsen, Recent, newtext)@EHDB 
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The first read action will be trapped by aspect A£|^, and the resulting substitution is 

[NsOlsen/user, MedicalRecord/recordiype] 

and the condition test (IMsOlsen, Medical Record, readJSDAC is evaluated. Since NsOlsen has 
the appropriate right according to DAC we proceed and perform this read action thereby giving 
rise to the binding of content to alicetext. 

The second action will not be trapped by any of the aspects, so it will simply be performed and 
the tuple (Alice, alicetext) is output to location NsOlsen. 

The last action will be trapped by aspect A°"^ and after the substitution we evaluate the 
condition test (IMsOlsen, Medical Record, out,)@DAC which is evaluated to ff and thus we break 
the execution. 

However, the KLAIM program can also execute read or in actions without specifying the 
record type, e.g., using /recordtype instead of recordtype, users can thus get a record as 
follows: 

NsOlsen :: read(Alice, Irecordtype, DrHansen, Past, lcontent)@EHDB 

where a successful input action can retrieve any type of EHR record. 

None of the above aspects can trap these input actions, thus we have to enforce additional 
aspects so that the above input actions will not bypass our aspects and consequently break the 
policy. The simple aspects forbid any attempts to read or in (read and then remove) EHR 
records without specifying the record type: 

A r p t^[user :: read(_, Irecordtype, _,_,_)@EHDB] 
= break 

Ap™ A5 [«ser :: in(_, Irecordtype, _,_,_)@EHDB] 
= break 

One may wonder why not build the above two aspects on top of aspects Ap^ and A p " A2 by 
directly replacing recordtype with /recordtype in their pointcut, respectively. The reason is 
that these aspects will not be well-formed: when trapping actions, recordtype binds with a 
variable, which cannot be used in a test condition such as test(user, recordtype, read)@DAC. 

4.2 Mandatory Access Control 

In this subsection we will show how to enforce the above policies by using mandatory access 
control (MAC), which is a means of restricting access to objects based on the sensitivity (as 
represented by a label) of the information contained in the objects and the formal autho- 
rization (i.e., clearance) of subjects j!8j. Before enforcing the above policy, we first impose a 
comparable classical MAC policy - the Bell-LaPadula security policy [1] based on a mandatory 
access control model. Later we enforce the above policy as a variant of the Bell-LaPadula 
policy. In the presentation, security levels are assigned to subjects (as clearances) and objects 
(as labels). 
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Example 4 In this scenario, we just need two security levels, and may assign security levels 
to subjects as follows: doctors have level high and nurses have level low; similarly we may 
assign objects as follows: private notes have level high and medical records have level low. 

To model this policy we need to introduce a location MAC that stores tuples of the form: 
(user, securitylevel) and (recordtype, securitylevel) . Continuing Example 0, we create the 
location MAC with the tuples: 

(DrSmith, high) 
(NsOlsen, low) 
(PrivateNote, high) 
(MedicalRecord, low) 

As before we also assume that the location MAC can only be modified by privileged users. 

Firstly, we enforce the Bell-LaPadula security policy to illustrate that AspectKE can enforce 
a well-known mandatory access control policy. Then we will enforce our example policy, with 
small modifications based on the aspects that enforce Bell-LaPadula policy. 

If we enforce the Bell-LaPadula security policy, the first part of the policy states that a subject 
is allowed to read or input data from any object provided that the subject's security level domi- 
nates that of the object. In our case, this guarantees no read up: that is, low subjects (nurses) 
cannot read high objects (private notes) but can only read low objects (medical records); how- 
ever, high subjects (doctors) can access both kinds of records. 

The no read up part of the policy can be enforced by aspects as follows: 

Apf®f[user :: read(_, recordtype, _,_,_)@EHDB] 

= case(-i(test(user, low)@MAC A test(recordtype, high)@MAC)) 
proceed; 
break 

The second part of the policy (a simplified form of Bell-LaPadula star property JI^J states that 
a subject can write to any object provided that the security level of the object dominates that 
of the subject (no write down,). In our case high subjects (doctors) cannot write low objects 
(medical records) but low subjects (nurses) can write to both kinds of records. 

The no write down of the policy can be enforced by the aspect below: 

A°^ 2 [user :: out(_, recordtype, _)@EHDB] 

= case (-1 (test (user, high)@MAC A test(recordtype, low)@MAC)) 
proceed; 
break 

Additionally, we have an aspect for the read action to prevent users from reading records 
without specifying the record type, and an aspect for the in action to prevent users from 
reading and deleting records: 

k r p \ a ^[user :: read(_, [recordtype, _, _,_)@EHDB] 
= break 

AXMser :: in(_,_,_,_,_)@EHDB] 
= break 
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These aspects correctly enforce our policy about reading patient records. However, the no write 
down policy is not quite right for our example, instead we depart from the Bell-LaPadula policy 
and define: 

A pi B * 2 , i user out(_,recordtype,_,_,_)@EHDB] 
= case(test (user, high)@MAC) 
proceed; 
break 

This aspect allows doctors to write any kind of record. 

The aspect Ap 1 "*^ together with A£f^, Apf^, A p ^ B4 reflect a mandatory access control model 
which satisfies our policy. In this case we only allow high users (doctors) to write patient 
records. Hence nurse NsOlsen in Example cannot execute the third action as it will be 
blocked by Ap 1 ^, , which would be allowed with A°^* 2 from the Bell-LaPadula security policy. 

4.3 Role-Based Access Control 

Role-based access control (RBAC) [TU] is another access control mechanism which allows the 
central administration of security policies and is often more flexible and elegant for modelling 
security policies. The simplest model in the RBAC family is RBACq, where there are three 
sets of entities called user, role, and permission. A user can be assigned multiple roles (role 
assignment) and a role can have multiple permissions (permission assignment) to correspond- 
ing operations. In addition, the user can initiate a session during which the user activates 
some subset of roles that he or she has been assigned. A user can execute an operation only 
if the user's active roles have the permission to perform that operation. 

Example 5 To implement the security policy for patient records, we use a model that does 
not differentiate a user's assigned role and active role (we assume that the assigned roles of 
all users are activated by default), so we only need location RDB with tuples (user, role) : 

(DrSmith, Doctor) 
(NsOlsen, Nurse) 

For permission assignment we also need a location to describe each role 's permission. This 
can be done by storing tuples (role, object, capability) at PDB; 

(Doctor, Medical Record, read) 
(Doctor, PrivateNote, read) 
(Doctor, Medical Record, out) 
(Doctor, PrivateNote, out) 
(Nurse, MedicalRecord, read) 

Once more we assume that the locations RDB and PDB can only be modified by privileged 
users. 
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The following aspects then implement the required policy: 

A^fluser :: read(_, recordtype, _,_,_)@EHDB] 
= case(3role G {Doctor, Nurse} : 

(test (user, ro/e)@RDB A test(ro/e, recordtype, read)@PDB)) 
proceed; 
break 

A*" C2 [user :: in(_, recordiupe, _,_,_)@EHDB] 
= case(3roZe 6 {Doctor, Nurse} : 

(test (user, ro/e)@RDB A test(roZe, recordtype, in)@PDB)) 
proceed; 
break 

Abuser :: out(_, recordtype ,_,_,_) @ E H D B] 
= case(3roZe 6 {Doctor, Nurse} : 

(test (user, ro/e)@RDB A test(ro/e, recordtype, out)@PDB)) 
proceed; 
break 



These three aspects are useful for interrupting the execution when a user attempts to operate 
on EHR records with a concrete record type, which essentially relies on the tuples from RDB 
and PDB. They also show the benefit of admitting quantifiers into the conditional expressions. 

Similar to the previous subsections, we have to enforce additional aspects for capturing user 
attempts to access EHR records without specifying the record type. 

A pic4 d [ user :: read (-> Recordtype, _,_,_)@EHDB] 
= break 

A J p " C5 [user :: in(_, [recordtype, _,_,_)@EHDB] 
= break 

In the following sections we will use the role-based access control mechanism since it is best 
suited for enforcing security policies in a large organization. 



4.4 Advice for Retrofitting Policies 

Now we will show how aspects in AspectKE can retrofit new security policies into an exiting 
system that is being developed/updated or has already been deployed. Concretely, when a 
new functionality has been introduced to the existing system we will show how we enforce new 
policies to cater for the new requirements (Section I4.4.1j) : when a policy has been proposed to 
refine existing policies, we will show how we enforce policies based on the existing functionality 
of the system (Section 14, 4. 2 j) : on the other hand, sometimes additional functionality has to be 
introduced to the system to implement aspects which refine existing policies (Section I4.4.3[) . 

Indeed, the possibility to refine, renew and retrofit security policies into an existing/evolving 
system is very important for IT systems. Taking the EHR system as an example, as the public 
debate about security standards (especially for privacy) evolves, governments have to modify 
the corresponding acts and guides. As a consequence, the security policy for an EHR system 
will undergo frequent change |20j . Moreover, the IT system itself will always be enhanced 
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by new functionalities, which means that new policies need to be enforced. The National IT 
Strategy for the Danish Health Care Service states that "it is also important to acknowledge 
the fact that IT is not just implemented once and for all" |21j. 

4.4.1 Enforcing Security Policy for New Functionality 

AspectKE can be used for enforcing new security policies when a new functionality has been 
introduced at any phase of the system development. The running example in Section 12.31 
introduces the functionality of the EHR system as regards reading and writing from and to 
the EHR database (EHDB). Now we introduce another (new) function to the EHR system 
that enables a manager to add a patient, or delete information from the system. 

In our programming model, each patient is represented by a location. A manager can add a 
new patient to the system as follows: 

MgDavis :: newloc(\patient) . out(patient, Patient)@RDB 

First a new location for the patient is created, then it is registered in the role database RDB 
by the out action. To delete a user one can simply perform an in action to the location RDB. 

We shall now show how to enforce the following security policy regarding the manager role at 
the hospital [H], for this new added functionality. 

In the hospital, only managers are allowed to add a user to, or delete from the 
system. 

Example 6 The following aspects will enforce the above security policy. 

A™ wloc [user :: newloc(_)] 

= case(test (user, Manager)@RDB A test(Manager, Location, newloc)@PDB) 
proceed; 
break 

A°f [user :: out(_, _)@RDB] 

= case (test (user, Manager)@RDB A test(Manager, RDB, out)@PDB) 
proceed; 
break 

Abuser :: in(_,_)@RDB] 

= case(test(user, Manager)@RDB A test(Manager, RDB, in)@PDB) 
proceed; 
break 

These aspects are composed in a way that is similar to the Example^ Before using them we 
need to put the tuple (MgDavis, Manager) into RDB and the tuples (Manager, Location, newloc), 
(Manager, RDB, out), and (Manager, RDB, in) into PDB. Finally, once again we assume that 
PDB can only be modified by privileged users. 

Example [6] shows that AspectKE can enforce a policy for new functionality (code), no matter 
when this functionality is developed, potentially in the entire life cycle of the EHR system. 
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This is because the underlying aspect-oriented mechanism allows new aspects to intercept 
all join points (including a join point of new code) and give appropriate advice. Example [6] 
also shows how to give advice on an action (newloc) that creates new node in a net. Note 
that Examples [5] and [6] use the role-based access control model which shows that the tuples 
introduced above at PDB are good at expressing permissions that only directly rely on roles 
and objects. However, some permission assignments are more complex and therefore we shall 
also use logical formulae to express permission assignments in the following sections. 

4.4.2 Refining Security Policy with Existing Functionality 

AspectKE can be used to to refine an existing security policy at any phase of the system 
development. The following is a policy which can be considered as a refinement of the previous 
policy (enforced by Example [3]l5]) to protect patients' privacy. This policy is also inspired by 

mi: 

Private notes can only be viewed on the basis of the doctor-patient confidentiality 
- doctors cannot view private notes that were not created by themselves; nurses 
can only view recent medical records which were created after the patient has been 
admitted. 

Traditional programming paradigms normally necessitate modifying existing code to enforce 
this extra policy, while the aspect approach simply requires additional aspects. 

Example 7 The first part of the policy can be expressed by the aspects shown below. These 
two aspects will prevent a doctor from reading a private note written by another doctor or 
reading a private note without clearly specifying the author of the note. 

A r p ^ d [user :: read(_, PrivateNote, author, _, _)@EHDB] 
= case(test(wser, Doctor)@RDB A (user = author)) 
proceed; 
case(-itest(wser, Doctor)@RDB) 

proceed; 
break 

A r p ^ d [user :: read(_, PrivateNote, [author, _, _) @ E H D B] 
= case (-.test (user, Doctor)@RDB) 
proceed; 
break 

Note that the second case of A r p f^ d and A r ^ d allow any users registered in RDB except doctors 
to read a private note, which includes users taking roles as nurses. Allowing nurses to read a 
private note is not problematic, as these two aspects only reflect the intention of this policy. 
Preventing nurses to read a private note is enforced in the previous policy. 

These two aspects are supposed to work together with those aspects defined in the Examples 
to For example if a nurse tries to read a private note, these aspects will proceed the 
execution but aspects in Examples\3^will suggest break. Another example is if a doctor tries 
to read a private note written by other doctors, aspects in Examples [3|[5| will allow the action 
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to proceed whilst these aspects will break the execution. Since break takes precedence over 
proceed, the final decision suggested from this advice will be to block the execution in both 
cases. 

The second part of the policy says that nurses can only read recent medical records which 
can be expressed by the following aspects where, once again, the aspects should be considered 
in conjunction with those of Examples [3] to These two aspects will prevent a nurse from 
reading a past medical record or reading a medical record without specifying the created time. 

k r p l1 d [user :: read(_, M edica I Record, _, createdtime, _) @ E H D B] 
= case(test(user, Nurse)@RDB A createdtime = Recent) 
proceed; 
case(-itest(user, Nurse)@RDB) 

proceed; 
break 

k r p l a t d [user :: read(_, Med ica I Record, _, \ createdtime, _)@EHDB] 
= case (-.test (user, Nurse)@RDB) 
proceed; 
break 

Note that no new functionality is required to enforce this policy, as these aspects only rely on 
the existing program (i.e., node RDB). 

4.4.3 Refining Security Policy with New Functionality 

Sometimes refining an existing security policy is necessary. We have to introduce additional 
functionality to support the implementation of the aspects for policy refinement. Now we 
consider the following security policy that restricts access to the database to certain locations 
in the hospital |22j : 

A nurse can only read medical records of the patients who are in the wards located 
on the nurse's working floor. Furthermore, the nurse can only access medical 
records through the computers that are located on that specific floor. But in the 
emergency room, a nurse does not have this restriction. 

Example 8 To express this policy as aspects we shall assume that the current location database 
CLDB records every user's current location information (indicating that they are using com- 
puters at that location), and that the assigned location database ALDB stores every user's 
assigned room (e.g. for nurses this is their working floors and rooms which they are responsi- 
ble for; for patients this is the floors and wards that they are on). These two databases store 
tuples with the same fields (user, floor, room) and can only be modified by privileged users. 

The set Floor contains the actual floors of the hospital (e.g. fl,f2^. The set Room contains 
the actual rooms of the hospital and includes two types of rooms: ordinary wards (e.g. wl,w2) 
and the special room EmergencyRoom. 
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The appropriate advice can now be expressed as follows: 

A r p ^ d [user :: re&d(patient, MedicalRecord,_,_,_)@EHDB] 
= case(test(wser, Nurse)@RDBA 

3 floor E Floor : test(user, floor, EmergencyRoom)@CLDB) 
proceed; 
case (test (user, Nurse)@RDBA 

Bfloor 6 Floor Broom € Room : ( test (user, floor, room)@CLDBA 

test(user, floor, room)@ALDB/\ 
test (patient, floor, room)@ALDB)) 

proceed; 
case(-itest(wser, Nurse)@RDB) 

proceed; 
break 

A r p ^ d [user :: read(!patient, MedicalRecord,_,_,_)@EHDB] 
= case(test(user, Nurse)@RDBA 

3floor G Floor : test(user, floor, EmergencyRoom)@CLDB) 
proceed; 
case(-itest(user, Nurse)@RDB) 

proceed; 
break 

In Ap|" rf , the first case caters for the situation where a nurse is working in the emergency 
room; the second case allows the read action when a nurse is trying to access the medical 
record for a patient who is on the same ward/floor as where the nurse is currently at and 
assigned to work, the third case allows a user who is not a nurse to perform the read action. 
The aspect Ap|" is similar to the aspect Ap|" except that it does not contain the second case. 
This is because reading a medical record without specifying the name of the patient is not 
acceptable for a nurse who is not working in the emergency room. 

As in Example^ these aspects will work together with all previously introduced security polices. 
Moreover, these aspects are both in the spirit of role-based access control, and they demonstrate 
that when composing aspects in AspectKE for larger and more complex security policies of an 
organization, role-based access control can be very efficacious, as has already been observed in 
the literature fWj/. 

Note new functionality has to be introduced to enforce this policy such as the newly introduced 
nodes for databases (e.g., CLDB, ALDB). This new functionality can be developed as part of 
the main logic of the EHR system, or can be merely developed and maintained to enforce 
security policies. We observe that although we might need to extend the functionality of 
the system's main logic to enforce certain security policies, the policies themselves are still 
described in aspects (even though they directly or indirectly rely on new nodes/processes), 
which are still separated out of the main logic. 
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5 AspectKE: Trapping Processes 



5.1 Motivation 

Classical reference monitors are incapable of enforcing security policies based on the future 
behavior of programs, rather they rely only on information gathered by monitoring execution 
steps [23], and perform history-based dynamic checks. However, security polices concerned 
with information flow that cannot be implemented correctly without a security check of the 
overall behavior of the program exist. 

For example, in a software system, remote evaluation involves the transmission of programs 
from a client to a server for subsequent execution at the server. However, as the programs 
transmitted might perform unintended operations at the server side, a security check is usually 
needed. A typical example of this is Java applets which can be transferred to a remote system 
and executed by the Java Virtual Machine (JVM). Since the unknown applets are not always 
written by trusted users, the JVM has certain mechanisms for ensuring that the applet will 
not be able to do malicious actions, e.g., the bytecode verifier [23] and sandbox mechanism 
[25]. 

As another example, in the EHR domain, rather than enforcing the primary use of data 
policies for direct patient care domain as shown in the previous sections, there is a trend 
to define and enforce secondary use of data policies. Here data is used outside of direct 
health care delivery that includes activities such as analysis, research, public health etc, even 
though it still lacks a robust infrastructure of policies and is surrounded with complex ethical, 
political, technical and social issues [12]. Compared with primary use of data, whose focus is 
on regulating "someone has some rights to access some data", it focuses on defining "how the 
data can be used after it is released to someone". The enforcement of such policies requires 
security checks in the form of inspection of the flow of data. 

In general, program analysis techniques concern computing reliable, approximate information 
about the dynamic behavior of programs [26] . and the derivation of useful information by 
simulating execution of all possible paths of the executing program. For example, type systems 
can be used to enforce various kinds of information flow as well as access control security 
policies (like Jif [27] for Java). 

In this section, we extend the AspectKE language presented in Section [3] which enables 
AspectKE not only to trap the action, but also to trap a process that is to be executed 
in the future. The process can be a process that is to be sent to a remote site, or a process 
continuation of a trapped action. This enables us to perform simple forms of program analy- 
ses, called behavior analysis, that syntactically inspect the trapped processes, i.e., actions in 
a new thread to be executed (at local/remote sites) or the remaining actions in the current 
thread. In the following section, we will show how to use simple behavior analysis techniques 
to enforce various security policies that require checking of the future behavior of a program, 
the so-called predictive access control policies, and that detect and prevent execution of the 
potential malicious operations at the earliest stage. 
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5.2 Extended Syntax and Semantics 



cut £ Cut cut :.= ■ ■ ■ | £ :: ca.X 

cond £ BExp cone? ::= • ■ • c £ set | £ £ set | set = 

set £ Set set ::= ■ ■ • | {c} | Act(X) | Loc c (X) | FV(X) | FV c pf) | LC(X) | LC C (X) | LVar, 



Table 3: AspectKE Syntax - Aspects for Trapping Processes 
Table [3] shows the extended syntax of AspectKE. 

The pointcut (Cut) in Table [2] has been extended with I :: ca.X, which not only binds the 
action, but also binds the program continuation after the trapped action to a variable X. 

Table [3] extends BExp and set in Table [2 which can be used for defining properties that re- 
quire syntactic analysis of the processes to be executed (usually the continuation of the trapped 
action bound by X). The set-forming behavior analysis functions Act, Loc c , LC, LC C , FV, FV C 
will be explained in the following sections when needed, but we have collected their definitions 
in Table H] where fv , bv , Ic, cap and loc are the obvious extraction functions for free variables, 
bound variables, location constants, capabilities and target locations, respectively. 

Note these functions expose different data-flow information of processes bound by process 
variables, and can be used to enforce predictive access control policies, namely access control 
policies that depend on the future behavior of a program. 



Example 9 To illustrate how aspects in the extended AspectKE trap a KLAIM program and 
extract its properties, the following aspect gives advice to the running example in section \2.3l 

k r 2 ead [user :: read(_,_,_,_,_)@DrSmith.X] 
= case (out £ kct(X)) 
break; 
proceed 

This aspect traps a read action of processes running at location DrSmith, when reading a tuple 
with five fields. The process continuation of the trapped action will be recorded in variable X. 
Function Act returns all actions in processes represented by X. If the actual process bound 
by X contains any out actions, the aspect will break the execution of the action and its 
continuation process. Otherwise, the action continues. 



Suppose we have a system that contains the same net as in running example of Section [K 
and aspect k™ 0,4 ": 



k r 2 ead [user :: read(_,_,_,_,_)@DrSmith.X] 

in 

proceed 



= case(emt £ kct{X)) 
break; 
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Act(Pi|P 2 ) 

Act^SiOi-Pi) 

Act(*P) 


= Act(Pi) U Act(P 2 ) 

= U(W(a l )}UAct(P l )) 

= Act(P) 


Loc c (Pi|P 2 ) 

Loc c (Siai.Pi) 

Loc c (*P) 


= Loc c (Pi) U Loc c (P 2 ) 

= Ui({^ oc ( a 1 cap(ai) = c} U Loc c (Pj)) 

= Loc c (P) 


LC(Pi|P 2 ) 

LC^ai.Pi) 

LC(*P) 


= LC(Pi) U LC(P 2 ) 
= UiMai) U LC(Pi)) 
= LC(P) 


LC c (Pi|P 2 ) 

LCcCEidi.Pi) 

LC C (*P) 


= LQ(Pi) U LC C (P 2 ) 

= U({^(ai) | cap(a 4 ) = c} U LC(P 4 )) 

= LC C (P) 


FV(Pi|P 2 ) 

FV(E ia ,.P 4 ) 

FV(*P) 


= FV(Pi) U FV(P 2 ) 

= U(/«(a<)U(FV(P0\6«(oi))) 
= FV(P) 


FV C (P!|P 2 ) 

FVcCEifli.Pi) 

FV C (*P) 


= FV c (Pi)UFV c (P 2 ) 

= Ui({/"(oi) 1 cap(«i) = c} U (FV C (P,) \ ^(a*))) 
= FV C (P) 



Table 4: Behavior Analysis Functions 



EHDB :: (Alice, Medical Record, DrHansen, Past, alicetext) 
|| EHDB :: (Bob, PrivateNote, DrJensen, Recent, bobtext) 
|| DrSmith :: read(Alice, MedicalRecord, DrHansen, Past, \content)@EHDB. 
out(Alice, content)@DrSm\th. 

out(Alice, MedicalRecord, DrSmith, Recent, newtext)@EHDB 

and some steps of execution (omitting the aspect definition): 

EHDB :: (Alice, MedicalRecord, DrHansen, Past, alicetext) 
|| EHDB :: (Bob, PrivateNote, DrJensen, Recent, bobtext) 
II DrSmith :: read(Alice, MedicalRecord, DrHansen, Past, \content)@EHDB. 
out(Alice, co?iient)@DrSmith. 

out(Alice, MedicalRecord, DrSmith, Recent, newtext)@EHDB 

EHDB :: (Alice, MedicalRecord, DrHansen, Past, alicetext) 
|| EHDB :: (Bob, PrivateNote, DrJensen, Recent, bobtext) 
|| DrSmith :: 

Aspect IK^ ad traps the read action, whose result substitution is 

[DrSmith/wser, 

out(Alice, coriien£)@DrSmith.out(Alice, MedicalRecord, DrSmith, Recent, newtext)@EHDB/X] 
Here Act(P) C {out, in, read, eval, newloc} is the set of capabilities performed by the process 
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P (see Table^4ty. In this case, Act returns set {out}, the case condition evaluates to tt, thus 
the aspect breaks the execution of this action and its continuation process. 

6 Worked Examples: Advice for Usage Control 

In this section, we now show how to use the extended AspectKE to enforce security policies 
that require behavior analyses of processes to be executed in the future, and we clarify the 
meaning of set-forming behavior analysis functions (from Set in Table [3] and H]) through 
examples - enforcing several predictive access control EHR security polices to the target EHR 
system presented in Section 12.31 In Section 16.11 we show how to enforce policies by utilizing 
the set-forming functions that check properties of remotely evaluating processes. In Section 
16.21 we show how to enforce policies by checking properties of the continuation process at the 
current thread. 

6.1 Remote Evaluation 

Using the action eval, AspectKE can easily express a process's remote evaluation. More- 
over, using behavior analysis, AspectKE can check the content of the transmitted process 
by composing various aspects that embody different security considerations. This gives us a 
flexible way of controlling the use of remote processes. We will enforce a security policy in a 
distributed mobile environment that has to consider both direct and indirect access to tuple 
spaces, and in the latter case AspectKE shows great usefulness. 

Consider a policy concerning removal of data from the system [11] : 

Doctors, nurses and patients are not allowed to delete records from the database - 
only the administrator of the database can do that. 

Thus, in terms of AspectKE, only the administrator is allowed to perform an in action on the 
EHR database. 

Example 10 In section \4^T§4-3[ we introduced aspects for restricting the in actions to access 
the EHR database when enforcing a basic access control policy. Here we shall slightly update 
them to reflect the new policy. As we prefer to use the role-based access control model, we 
show how to update the relevant aspects in Section \4-3\ 

For aspect Apf"^, we need to add role Administrator to role set, while updating tuple spaces RDB 
with tuple (AdWalker, Administrator), and PDB with tuples (Administrator, Medical Record, in) 
and (Administrator, PrivateNote, in). 

In aspect A*™ , we have forbidden all users to delete records from the EHR database. Now 
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we relax this requirement and replace it with the following aspect. 



Abuser :: in(_, Irecordtype, _, _,_)@EHDB] 
= case (test (user, Administrator)@RDB 
proceed; 
break 

This breaks direct attempts to perform in actions, only actions by the administrator are al- 
lowed. 

This advice only deals with direct attempts to delete data; we also have to cater for processes 
like 

NsOlsen :: eval^in(paiieni, Irecordtype, \author, Icreatedtime, \subject)@EHDBj 
@ Ad Walker 

where anyone (e.g., NsOlsen) who spawns an arbitrary process on the administrator Ad- 
Walker's node can behave as an administrator and delete the records. 

This behavior can be captured by an aspect for eval actions that targets the Ad Walker location, 
without using any behavior analysis functions. 

kllf [user :: eval(F)@AdWalker.X] 

= case(test(user, Administrator)@RDB) 
proceed; 
break 

However, this aspect is too restrictive as it disallows the possibility for other users to perform 
well-behaved actions on behalf of an administrator (e.g., out, read etc.). 

Using behavior analysis functions, we are able to check the process in advance so that less re- 
strictive policies can be enforced. For example, the following aspect prevents remotely spawned 
in actions on Ad Walker, but allows other types of action. 

Abuser :: eval(y)@AdWalker.X] 

= case(test (user, Administrator)@RDB) 
proceed; 

case(test(user,_)@RDB A ^(in E Act(F))) 

proceed; 
break 

Here Act(P) is the set of capabilities performed by the process P (see Table It follows 
that any in actions within Y will be trapped. There is no restriction for actions other than in 
actions, so remote code can still perform actions like out and read. 

We may want to be more liberal and allow in actions on locations distinct from EHDB. To do 
so we introduce LoCi n (P) to be the set of locations i, where in(- • -)@£ occur in P; note that 
this set may include location constants as well as location variables (see Table\l^. 
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Rather than aspects Apg" and Algjj , we could use the aspect: 

Aps° z [user :: eval(F)@AdWalker.X] 

= case (test (user, Administrator)@RDB) 
proceed; 

case(test(user,_)@RDB A (LVar* U {EHDB}) n Loc in (r) = 0) 

proceed; 
break 

where LVar* is the set of all location variables in the program. This aspect allows users to 
perform an in action on behalf of an administrator when the target locations will never be 
EHDB ; which is the least restrictive aspect for enforcing the same policy. 

Example [10] shows that whilst security policies may be very simple to enforce superficially, 
execution of remotely spawned code might easily invalidate policies which appear to be rea- 
sonable. Using aspects, we are able to elegantly update the enforcement of the security policy 
to cater for this. Furthermore, the examples also illustrate AspectKE's capability of checking 
the remote code before it is executed, which gives the users greater flexibility to enforce a less 
restrictive but more precise policy. 

One might wonder whether combining the use of newloc and eval actions will break the 
above security policies. Consider the following example: 

NsOlsen :: newloc(!u).out(u, Administrator)@RDB. 

eval(in(patient, Irecordtype, \author, Icreatedtime, lsubject)@EHDBj@u 

Here NsOlsen tries to create a new location, register it to RDB, then execute the in action 
from the new location. This attempt will not work: if policy fi i ^ wloc and A°2* from Example 
[6] are still enforced, NsOlsen is neither able to create any new location nor update RDB since 
only a Manager can do that. 

In fact, all aspects defined in this paper will directly break any action executed at a location 
that has not been registered in RDB, and this includes all attempts to use newloc and eval 
to bypass the security policies as shown above, as only the manager can update RDB through 
aspects defined in Example [6l 



6.2 Using Program Continuations 

Now we show how AspectKE can trap the continuation process and use behavior analysis 
functions to get the future behavior of the executing process, which enables the advice to 
control and avoid executing the malicious processes as early as possible. 

As we have mentioned before, our society is moving in the direction of trying to exploit patient 
healthcare records that already exist for new purposes (known as secondary use of data). At 
the Canadian Institute of Health Research [28] it is stated that "health research based on the 
secondary use of data contributes to our present level of understanding of the causes, patterns 
of expression and natural history of diseases." This raises new challenges for developing an 
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effective system to ensure people's rights to privacy and confidentiality: decisions concerning 
access control decisions are not only based on the right of access of different principals but 
should also examine how the data is to be used after access has been provided. 

For example, researchers who are making secondary use of data should not be able to access 
the identity of patients. Therefore we want to prevent them from executing a process like 

RsMiller :: read{patient, Irecordtype, lauthor, Icreatedtime, Isubj eci)@EHDB 

which explicitly specifies the patient whose records the researcher is interested in reading. We 
can easily compose aspects that forbid the researcher from performing such actions (but allow 
nurses, doctors, etc . . . ) that are similar to those aspects that have been shown in Section [H 

In order for the researcher to blindly get a patient's healthcare record, the researcher may 
perform a process such as 

RsMiller :: read{lpatient, recordtype, lauthor, Icreatedtime, Isubj eci)@EHDB 

The difference between the read action in this program and those in the previous examples is 
the use of ! in front of patient, i.e., the researcher does not specify which patient's healthcare 
record is to be read. However, after the researcher has obtained the healthcare record, s/he 
can still use the patient's identity. We might want to prevent the researcher from executing 
a process like 

RsMiller :: re&d(lpatient, Medical Record, lauthor, Icreatedtime, lsubject)@EHDB. - > 

out {patient, su6jeci)@Publication ^ ' 

whereas it would be acceptable to execute the process 

RsMiller :: re&d{lpatient, MedicalRecord, lauthor, Icreatedtime, !sM&jeci)@EHDB. , . 

out(sw6ject)@Publication 

since the second program will not use the identity of the patient whose record has been 
selected. 

The following policy is extensively discussed and accepted around the world and is specified 
directly or indirectly in a number of codes (e.g. [TTJ [28j USE [12]): 

Researchers should not read and use the patient's healthcare records of an EHR 
system in a way that might potentially expose the identity of the patient. 

Example 11 The following aspects, which replace the aspects Apf"^ and A£f"^ in Example^ 
enforce this policy, which enforce both the basic access control policies for doctors and nurses, 
and policies for the researchers regarding their rights to read EHR records. It is necessary to 
revise the aspects because our previous development was only for primary use of data. 



Apg° d [user :: re&d {patient, recordtype, _,_,_)@EHDB.X] 
= c&se{3role £ {Doctor, Nurse} : 

(test (user, ro/e)@RDB A test(roZe, recordtype, read)@PDB)) 
proceed; 
break 

Apg° d [user :: re&d{patient, Irecordtype, _)@EHDB.X] 
= break 
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Apg° d [wser :: read(lpatient, recordtype, _)@E\-\DB.X] 
= case(3ro/e 6 {Doctor, Nurse} : 

(test (user, ro/e)@RDB A test(roZe, recordtype, read)@PDB)) 
proceed; 

case(test (user, Researcher)@RDB A -^(patient G FV(X))) 

proceed; 
break 

Apg° d [user :: re&d(lpatient, Irecordtype, _, _, _)@EHDB.X] 

= case(test(user, Researcher)@RDB A -^(patient <E FV(X))) 
proceed; 
break 



Aspect Apf"^ is replaced/ divided by aspects Ap|° and Ap§" , according to whether a patient 
name is clearly specified or not. Similarly, Apf"^ is replaced/divided by aspects A p g" rf and 
A p g" d . In both cases, additional conditions regarding researchers are only added to aspects 
when a patient name is not specified, i.e., Ap|° rf and Ap|" d . In these two aspects, the behavior 
analysis function FV is used, which returns the set of free variables of P (see Table^. 

In our case the aspect A£g" will bind X with the out actions of the above two programs: in pro- 
gram ([TP with out(patient, subject)@Pub\\cat\on , and in program ^ with out(su&jeci)@Publication. 
Thus ^(patient € F\/(X)) would be evaluated to ff for the first case and to tt for the second 
case. Using this extra information from the behavior analysis function, the advice can be based 
on some properties of the future execution of the continuation process ( in particular, whether 
or not patient will ever be used). And the suggestions from aspect Apg" d would be break 
for the first case and proceed for the second one. Note at the point that the access control 
decision has been made, Ipatient in the join point read action is still a defining occurrence 
variable and thus does not bind with any actual location yet, and behavior analysis merely 
analyses the future behavior of process based on its static information. 



The above aspect is too restrictive since it forbids the execution of meaningful read actions 
as well. As one of the case studies performed by the Canadian Government |28] indicates: 

In practice, the researchers might need to do some data linkage operations between 
different databases. 

For example, we may allow the researcher to extract several records for the same patient from 
different databases and put that information together as in the process 

RsMiller :: re&d(lpatient, Medical Record, \author, \createdtime, \subjectl )@EHDB. 

re&d(patient, MedicalRecord, lauthor, Icreatedtime, !su6jec^)@EHDB2. (3) 
out(subjectl , su&jec^)@Publication 

where we introduce another EHR database EHDB2 that is located at another hospital. 

Now there are two databases so we need to consider which policies are suitable for each 
of them, respectively. For illustration purposes, we might simply demand that the second 
database has the same security policy as the original one. Thus the second read action would 
be denied, since the original policy prohibits a researcher from reading a specific patient's 
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healthcare record. Because of this, establishing data linkage in the direct manner of program 
([3]) will never work. 

To make the data linkage work we can restrict the researcher's access to the data through 
a trusted location (EHDB for example) by remote evaluation, and let the trusted location 
perform the actual data linkage actions. In this way the policy will allow the second read 
action whenever it is executed from the trusted location: 

RsMiller :: eval(^rea.d(lpatient, Medical Record, lauthor, Icreatedtime, lsubjectl)@EHDB. 

re&d(patient, MedicalRecord, lauthor, Icreatedtime, lsubject2)@EHDB2. . , 

out (sub jectl , sitfejec^)@Publication ' 

)@EHDB 



As demonstrated in the last subsection, if remote evaluation is allowed, we need to pay closer 
attention to the overall security of the system. For example, in the event that the researcher 
attempts to get a doctor to link databases and output the private information as in 

RsMiller :: eval^read(!patient, MedicalRecord, lauthor, Icreatedtime, lsubjectl)@EHDB. 

re&d(patient, MedicalRecord, lauthor, Icreatedtime, !su6jeci2)@EHDB2. , , 

out (patient, subjectl , subject2)@P ub\'\cat\or\ 

)@DrSmith 

or in the event that the researcher attempts to obtain the records of a patient whose name is 
selected from his own tuple space either before evaluating a process at an EHR database or 
during the evaluation procedure. 

RsMiller :: read(!paiierrf)@RsMiller. 

eval^read (patient, MedicalRecord, lauthor, Icreatedtime, !s«6jecW)@EHDB. 

rea.d(patient, MedicalRecord, lauthor, Icreatedtime, lsubject2)@EHDB2. (6) 
out(patient, subjectl, sM6jeci2)@Publication 

)@DrSmith 

RsMiller :: eval(read(!pataerrf)@RsMiller. 

re&d(patient, MedicalRecord, lauthor, Icreatedtime, lsubjectl)@EHDB. 
read(patient, MedicalRecord, lauthor, Icreatedtime, lsubject2)@EHDB2. (7) 
out(patient, subjectl , subject2)@Pub\\cat\on 

)@DrSmith 

we need an aspect that inspects the actions performed by a researcher performing an eval 
action on all the EHR databases or locations other than the EHR databases. 
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Example 12 This motivates the aspect: 

k e ™ l [ U ser :: eval(Y)@dest.X] 

= case (test (user, Researcher)@RDB A test(dest, DataBase)@RDB)A 
Vx G LC read (y) : -.(test (a;, Patient)@RDB)A 
Vy £ Loc rea d(^) ■ (test(y, DataBase)@RDB) ) 
proceed; 
case (test (user, Researcher)@RDBA 

(-.test (desi, DataBase)@RDB A test(dest,_)@RDB)A 
Vx 6 Loc out (y) : (test (a:, DataBase) Vie {dest}) ) 
proceed; 

case(^test(user, Researcher)@RDB A test (•user, _)) 

proceed; 
break 

T/ie /zrsi case 0/ i/ie aspect ensures that a researcher can directly evaluate processes in the 
EHR databases if s/he is not able to get the name of the patient whose record s/he is trying to 
obtain either before evaluation or during evaluation (by reading a patient name from a location 
other than EHR databases). Note that LC rea d(-P) is a set of location constants in read actions 
of process P (defined in Table\4ty- The second case guarantees that when sending a process to 
other remote locations, the process only contains out actions that are performed on the EHR 
databases (trusted locations) or the tuple space associated with that remote location. 

In summary, the examples in this section show the versatility of AspectKE when dealing with 
remote evaluation and future execution paths of processes. We illustrated the usefulness of 
each behavior analysis function when enforcing access control policies that requires the future 
behavior of process. When selecting the appropriate behavior analysis functions, it is possible 
to enforce less restrictive policies and avoid the execution of malicious processes as early as 
possible. More importantly, in a highly complex and privacy related computing environment, 
with policies that are changed frequently such as the EHR system, enforcing various access 
control and data usage policies through security aspects shows the potential of being a very 
flexible and elegant approach. 

7 Related Work 

7.1 Policy Enforcement Mechanisms and Aspect Oriented Programming 

There are various techniques for enforcing security policies, the most traditional one is a 
reference monitor that observes software execution and dynamically mediates all access to 
objects by subjects. Instead of mixing the monitoring code in the target system, Inlined 
Reference Monitors (IRMs) [2] use a load-time, trusted program rewriter to insert security 
code into a target application, resulting in a self-monitoring application that performs security 
checks as it executes. There are many IRM systems implemented by various program rewriter s 
(e.g. [30j EJ [32j [33] ) , ensuring that different types of application will obey their corresponding 
security policies. 
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Independently, the aspect-oriented programming (AOP) paradigm [3] has emerged and has 
served as another effective mechanism for tackling the same issue. Indeed security is naturally 
identified as one kind of crosscutting concern that aspect-oriented programming was designed 
to deal with: instead of using a rewriter to inject monitoring code, security policies are coded 
through aspects which are invoked when the target program executes certain actions. There is 
a close connection between AOP and IRM. Hamlen and Jones |34j propose an aspect-oriented 
security policy specification language SPoX for enforcement by IRMs which establish a formal 
connection between AOP and IRMs. JavaMOP|35] implements IRM by using Aspect J aspects 
as the instrumentation mechanism. AspectKE takes the AOP approach to internalize the 
reference monitor for enforcing security policy to tuple space systems, and directly encodes 
security concerns in aspects. 

Most research focuses on the class of security policies that can be enforced by monitoring 
execution of a target system |23j and hence are enforceable by traditional reference monitors. 
AspectKE allows us to perform a behavior analysis on future execution of the target system, 
giving us the capability of enforcing policies that go beyond reference monitors. In [36], the 
authors outline several promising methods for enforcing security policies: IRM, type systems 
and certifying compilers. The authors also argue that synergies among these approaches will 
achieve remarkable results. We believe our approach - aspects with behavior analysis - is 
comparable as an alternative to IRM with Type systems. 

Several AOP languages can identify the data-flow and control-flow between join points, which 
can serve as powerful policy enforcement mechanisms. AspectJ's cflow[3] captures the control 
flow between join points. Dataflow pointcut [37] identifies join points based on the dataflow of 
information. Tr acematches [38] can give advice based on the execution history of computation. 
However, these systems can only refer to the past and current events, in contrast AspectKE 
can refer to future events. A few AOP languages propose mechanisms so that aspects can 
be triggered by control flow of a program in the future, e.g, pcflow[39] and trans cut [40] . 
however, they lack support for providing dataflow information in the future as AspectKE does. 
Some advanced AOP languages (e.g..[41[!42j) offer ways of referring to the future behavior of a 
program in the aspect, which in theory can be used for specifying security policies that depend 
on the future control-flow and data-flow. However, as they usually lack formal semantics and 
also normally only offer access to low level (e.g., bytecode-level) information of a program, 
this makes it hard to understand and develop appropriate underlying analyses for enforcing 
security policies. Moreover, they lack high level abstraction for presenting the analysis results 
as AspectKE's behavior analysis functions do, which makes it non-trivial to use the results for 
composing security policies. The formal semantics of AspectKE clarifies the way of developing 
useful behavior (program) analyses and presenting the analysis results through appropriate 
language abstraction, and formally pave a way of integrating program analysis techniques into 
the policy specification and enforcement procedure. 

7.2 Security With Aspect-Oriented Programming 

There are many papers that explore the AOP mechanism to enforce security policies. One 
line of work directly or indirectly use the popular Java-based general purpose AOP languages 
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like Aspect J [3j, Hyper/J [33], Caesar J [33] to express and enforce security policies. 

In [35] the authors present general guidelines for how to compose access control aspects in 
AspectJ, while in [36] an enforcement of application-specific policies in an access control 
service is implemented in CaesarJ. Phung and Sands [8] identify classes of reference monitor- 
style policies that can be defined and enforced by AspectJ and present a method to realize 
some history-dependent security policies which cannot be naturally expressed in AspectJ. 
Ramachandran et al. [47] discuss using AspectJ for implementing multilevel security and 
demonstrate how aspects, in comparison to traditional programming, can guarantee better 
security assurance. Similarly, AspectKE can be used to enforce a wide range of security 
policies but focuses on access control and explicit flow of information. 

Oliveira et al. [48] use their own rewrite-based system to express access control policies and 
then map them into an AspectJ program; in [39], availability requirements are expressed 
in a formal model that combines deontic and temporal logics, and are then translated into 
availability aspects in AspectJ. One advantage of these approaches is that policies can be 
formalized through security oriented languages which are more suitable for security consider- 
ations than general purpose languages, another advantage is that some policy languages have 
a formal semantics which enables formal verification. AspectKE is designed with security in 
mind and has a formal semantics which will enable us to reason about the AspectKE's policies 
in future work. 

Even though these well-known AOP languages are industrial strength and can be readily 
used for a policy enforcement mechanism, they have their limitations: it is very hard to 
apply these AOP languages to the types of systems we have been studying. For example, the 
languages are designed for programs that run on a local machine, and they do not naturally 
support pointcuts for a distributed system. They also lack a pointcut mechanism to capture 
the future execution of a program, and thus are unable to enforce predictive access control 
policies. These issues are explicitly addressed by AspectKE. Particularly, we are the first to 
report how to use aspect oriented programming techniques to enforce secondary use of data 
policies that are becoming increasingly important in large IT systems. 

As we have done, some researchers design their own special purpose aspect languages or 
systems to study security enforcement mechanisms. For example, HarmlessAML [5] is an 
aspect-oriented extension of Standard ML, and has a type system that guarantees well-typed 
harmless advice does not interfere with mainline logic computation. AspectKE is an aspect- 
oriented extension of a tuple space system, with a different research focus, aim at enforcing 
access control policies to a distributed computing model and studying how properties obtained 
from the behavior analyses can be used to specify access control policies. As mentioned earlier, 
in [37] the dataflow pointcut is proposed which specifies where aspects should be applied based 
on the origins of values in the past execution, which is useful in a situation where flow of 
information is important. AspectKE tackles similar issues, but checks the flow of information 
in the future. 
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7.3 Distribution with Aspect-Oriented Programming 

Much work has been done regarding how to deploy and weave aspects for distributed systems: 
some work is relevant for language design of distributed AOP with explicit distribution [50\ 
EH [52], other work explores the implementation of AOP middleware to support distributed 
AOP |53t [5^1 I55j . AspectKE is closer to the language design of distributed AOP which 
naturally follows the KLAIM programming model and uses remote pointcuts [50] that identify 
join points in a program running on a different location. However, AspectKE does not aim 
at enhancing the flexibility of mechanisms to deploy, instantiate and execute distributed 
aspects, e.g., support advice execution over remote hosts, as AWED [5]] and ReflexD [52] have 
achieved, rather it focuses on integrating analysis components for reasoning about the local 
or mobile processes to support advanced access control in a distributed setting. Compared 
with these languages, AspectKE provides a well defined security enforcement mechanism to 
tuple space systems that supports process mobility. 

A04BPEL[56] is an aspect extension of the process-oriented composition language BPEL, 
which was originally designed for composing Web Services. Work in [571 [58] discusses differ- 
ent principles of using AOP to implement coordination systems (in Aspect J), but that are 
not related to security. Recently, another variant of AspectK, AspectKB [59] has been pro- 
posed; it uses Belnap Logic to deal with conflicts when distributed advices are composed in a 
coordination environment. 

7.4 Security in Coordination Languages and Security Policy Languages 

AspectKE extends KLAIM, first presented in [10] , later evolved into the KLAIM family 
(reviewed in [60]), including cKlaim, OpenKlaim, HotKlaim, OKlaim and X-Klaim etc. The 
prototype language of KLAIM is Klava [61], implemented in Java and has proved to be suitable 
for programming many distributed applications involving code mobility and our AspectKE* 
prototype language [13] is built on top of it. Regarding policy enforcement of these languages, 
some authors use control and data flow analyses that are written in the Flow Logic approach 
(e.g. [62l [63]), others use type systems (e.g. [53]). and [65] combine these two lines of work. 
They can be used to enforce very advanced security policies, however, all of them require the 
user to explicitly annotate policies in the main code (e.g. attach policies to each location), 
while our approach avoids this by specifying them inside the aspects, thus achieving a better 
separation of concerns. 

Secure shared date-space coordination languages can be classified into two categories with 
regard to the underlying access control mechanisms [66]: the entity-driven approach (addi- 
tional information, associated to resources such as tuple spaces, tuples and single data fields, 
list the entities which are allowed to access the resources) e.g., Secure Lime [67] and KLAIM 
|10] ; and the knowledge-driven approach (resources are decorated with additional information 
and the processes can access the resources only in the event that they prove to keep the 
knowledge of such additional information) e.g., SecOS [68] and SecSpaces [69]. Our approach 
is suitable for expressing access control policies that fit both an entity-driven approach and a 
knowledge-driven approach, as the additional information is essentially expressed in aspects 
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and is directly embedded in neither resources nor processes. Moreover, this additional infor- 
mation is not limited to the past and current facts used in the previous work, e.g., password 
[ST], locks [68] or partitions [69], but also facts about the future, e.g., how particular data will 
be used, which is useful for enforcing predictive access control policies that only AspectKE 
can enforce. 

Binder [70] and Cassandra [20] are very powerful logic-based security policy languages, which 
are both based on the datalog logic-programming language. In |20] . there is a substantial 
case study performed using Cassandra that is based on the UK National Health Service 
procurement exercise. In AspectKE, our security policies are mainly expressed based on 
logical formulae and predicates in the aspects. The difference is AspectKE also provides 
predicates that can also describe future events. There are other prominent policy languages 
like Protune [7T] . Rei [72], Ponder [73], and Key Note [75] . which can express basic access 
control policies very well. Only Ponder and Rei can express usage control through obligation 
policies but, unlike our approach, neither language can enforce them and has to trust that 
the party receiving the data uses it in proper ways |75j . 

8 Conclusion 

8.1 Our Experience of a Proof-of-Concept Implementation 

We have designed and implemented a proof-of-concept programming language AspectKE* 
[13], based on the core concepts of AspectKE, which can be compiled and executed under 
a Java environment for building secure distributed systems and is freely distribute ci. The 
runtime system of AspectKE* is built on top of Klava [61]. Klava, a Java package that 
implements the core concept of KLAIM, can be used to program tuple space operations for 
building distributed systems. 

AspectKE* is generally implemented following the semantics of AspectKE, however, it takes 
a different approach regarding the implementation strategy of the behavior analyses. When 
aspects need the results of behavior analysis functions, AspectKE needs to perform the cor- 
responding behavior analyses at runtime for each step of program execution, which is not 
practical enough due to the potential large runtime overhead. On the other hand, AspectKE* 
uses a two-staged implementation strategy that gathers fundamental static analysis informa- 
tion at the process's load-time (the analyses are performed on the bytecode representation of 
the processes), and evaluates the program analysis predicates and functions (similar to the 
behavior analysis functions) at runtime by combining the results of the load-time analysis and 
runtime information, which efficiently implements the conceptual model of AspectKE. 

We implemented a secure tuple space based EHR workflow system in AspectKE*, and all 
aspects presented in the previous sections are implemented, except for aspect &pj al , as the 
behavior analysis functions LC and LC C are not currently supported by AspectKE*. Besides 
the EHR system, we also built a secure tuple space based chat application in AspectKE*. In 

2 http://www.graco.c.u-tokyo.ac.jp/ppp/projects/aspectklava.en 
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|13j we show how to enforce access control policies which require analysis of future behavior 
of a process onto a chat system that contains untrusted components. These two applications 
demonstrate that the AspectKE model can be efficiently implemented and executed in real 
world settings. 

8.2 Final Words and Future work 

We have presented AspectKE, an aspect-oriented extension of the coordination language 
KLAIM [76J. This has provided a concrete vehicle for presenting our approach; the distributed 
tuple spaces provide a natural model of the kind of system that motivated our work. However, 
the approach could equally well be applied to more classical process algebraic languages; the 
join points in this case being read and write accesses to channels. 

Compared with our previous work AspectK [77], AspectKE empowers aspects to trap not 
only the matched actions but also the process continuation and the processes being evaluated 
remotely. AspectKE also provides various behavior analysis functions and enables us to reason 
about the future execution of processes, which improves the capability of standard reference 
monitors that normally only deal with history based security policies. To achieve this, we 
simplify AspectK so that actions before and after proceed or break are not allowed. If we 
had allowed these actions, a safe behavior analysis would be very difficult to achieve, since 
the processes to be executed might execute more actions (inserted by aspects at runtime) than 
planned. This is an interesting direction for the future work and will require more powerful 
program analyses than the behavior analyses of the present paper. 

We evaluated the expressiveness of AspectKE by investigating its policy enforcement capabil- 
ity through examples in an EHR setting. We have demonstrated that AspectKE can enforce 
discretionary access control, mandatory access control as well as role-based access control. 
Furthermore, AspectKE can elegantly retrofit new policies to an existing system with mini- 
mum effort at any phase during the system development cycle. We have also shown that in 
a distributed and mobile system, the information flow is very hard to control. AspectKE can 
enforce a range of predictive access control policies to cater for this issue, through composing 
aspects that check remote evaluation and the program continuation. We enforce both primary 
and secondary use of data, which shows that AspectKE is suitable to cater for old as well 
as new challenges in such a complex distributed computing environment, where security and 
privacy are of great importance. We also briefly report the experience of our proof-of-concept 
implementation of AspectKE, namely AspectKE*, and its usage for enforcing the security 
policies presented in this paper to an EHR workflow system and enforcing other security 
policies to a chat application. 

The examples presented in this paper were chosen so as to illustrate the different character- 
istics of AspectKE, but they were also chosen so as to constitute a complete set of access 
control policies. Here we conjecture that our aspects indeed enforce the complete set of access 
control policies, but in order to validate our conjecture we need to apply a formal validation 
method to it. 

There are other challenging secondary use of data policies which require control not only of 
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direct flows but also of indirect flows [78]: e.g. after storing specific data into a doctor's 
own tuple space, the doctor should not allow them to be transferred into a researcher's tuple 
spaces by indirectly passing through another location. In this case, checking all the parallel 
executing processes with existing security aspects that rely on more advanced static analyses 
[26] might be needed (e.g. to predict all possible data that can be stored in a certain tuple 
space [621163]). 

We find that the combination of aspects with behavior and static analysis techniques shows 
great potential for serving as a flexible and powerful mechanism for policy enforcement, and 
as a promising method of building security and trust in a distributed and mobile environment. 
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